In the field of printing, it is generally desirable to maximize printing quality and printing speed at a printer. Customers tend to dislike any delay that occurs between sending a print job to a printer, and receiving the printed sheets of the print job. Therefore, printer manufacturers strive to optimize the physical printing speed of marking engines that mark printed sheets and the processing speed of devices that prepare incoming print jobs for printing by interpreting and rasterizing them.
In order to increase the processing speed for incoming print data, print controllers often include multiple Raster Image Processors (RIPs) that operate in parallel. The print controller splits the incoming print job into segments of data (e.g., logical pages), and sends the logical pages to the parallel RIPs for interpretation and rasterization. For example, each of the parallel RIPs may interpret incoming logical pages by generating a display list or other instructions for marking pels on a sheet. The parallel RIPs may further rasterize/render the logical pages into a sheetside image (“sheet image”) by placing pels in a bitmap with an appropriate mark/color based upon the generated display list.
Processing incoming print data using parallel RIPs is generally desirable because it increases the speed at which a print job may be interpreted and rasterized, which is often the most time consuming part of printing an incoming job. However, using multiple RIPs in parallel to generate a single sheetside image for a logical page remains a complicated process. Often, an incoming logical page exists in the form of print data according to a page description language (e.g., PostScript). This logical page may also be associated with a job ticket (e.g., a JDF job ticket), and the job ticket may indicate further graphical elements to place on the sheetside image for the logical page. These additional graphics, known as “relative page elements,” may include watermarks, headers, footers, and other graphics comprising text and/or symbols. Because these additional graphics are not part of the print data of the logical page itself, they do not accompany information that indicates the actual size and orientation of the page that they are intended for (i.e., the physical sheet upon which the graphics will be presented to a user). Instead, these graphics often use generic instructions indicating a relative location on a page. Examples could include “top,” “bottom,” “header,” “footer,” “centered,” “left,” “right,” and others. The exact location at which to rasterize these graphics within the sheetside image is therefore not determined until the logical page has already been interpreted and is being processed by a RIP. Because the location of these graphics cannot be determined until the logical page is already being interpreted by a single RIP, it remains a problem to process these graphics in parallel with the print data for the logical page in order to generate a sheetside image for the page.